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ABSTRACT 


This thesis presents one possible method of integrating the DMS and 
GBS systems. This effort is undertaken in order to explore how the DMS 
messaging capability can be extended to the mobile, tactical user via a new, 
more robust broadcast subsystem. The Navy's current Fleet Broadcast 
subsystem is not prepared to handle the increased traffic load expected from the 
conversion to DMS-based messaging. The application of GBS as a "next 
generation" Fleet Broadcast offers an expansive leap in tactical broadcast 
communication capability. 

DMS broadcast to the tactical environment via GBS is sehiedad through 
the application of relatively new, commercially developed network addressing 
and mobile-user routing protocols. Adaptation of a broadcast messaging 
capability into the DMS is also incorporated. Incompatibility issues are resolved 
at the transport and network layers instead of higher-layer data format 
conversion. The proposed communications architecture provides for a high 
data-rate message broadcast system, capable of carrying DMS traffic to mobile 


units. 








TABLE OF CONTENTS 


INTRODUCTION AND PROBLEM OUTLINE .0.00.....cecccccceccccccccccccccceesecceccessneeee 
A. THE. DMS GONGEP F cssccssii ie cosce ssscoe tiivcs vetucesanaecSeeaudaedanctdeneentauiel sonal 
1. Basic X.400 / X.500 Concepts 


a. DOO oaecatsecacteccapepactesuaads vesadtnnarianianesiae en astensecsee ai ataeeie ace: 
b. Pe DOO seers eae eesis caste esate tautunteeae aunt eueeteseie: 
2. DMS Role Within the DISN ....... i eeeereeceseneees 
3. DMS and the US Navy ................ ccc ececccccecscscceceseesseneaeeceseeeeeenens 


B. DMS IN THE CURRENT NAVY BROADCAST 
ENVIRONMENT ........................cccccsecccsecccscccsecceccencceusseuceseuseauceuceescenscencs 
1% Bandwidth Limitations 


2. Protocol Incompatibilities «2.0.0.0... eee eeesessseseeseeeeeeeeens 

a. Neen ada ead ieee ctecesc a dered aieia ees eaten on tw he 

b. X.400/TCP and Simplex Links ........... ee ceeeeessteteeeeees 

C. Mobile User Connectivity ................c cc ceeceecsceeesesceeeceeeeneeees 

3. DECUIMY CONCEINS scsseeidecsorsiesndastevaiaduindadapaerdicenssetecectescenveasantnnue: 

4. FPFODOSCd: SOLUTIONS esscasc2c.cdsceccicaewvacsuisoisonttierimnnnesaeneeadesaseneteds 

C. Bm.) che be ho) Gy Ba errr mn er eee en tee ana ere eer oer rene ae ee eee 
USN FLEET BROADCAST. 0.0.0... ieccecccsccesssecesssceseecssesasecessccnececeseseeenseeeeees 
A. NCTAMS PROCESSING.|..............ccccccsccssssesscccseceessescceseveeeeeceeseceeeesenecs 
1. Message Processing. ............cccccccccccccccesssccsececsceceveceeeeeeauenseesnenses 

Z. Message Transmission .................:cccccscccceseescseessseseceuseceeeceenauees 


B. NAVCOMPARS II 


C. FLEET BROADCAST SYSTEM LIMITATIONS 


ape e@ecaaeeaeweraenatrepeareeaeneene eae ntaecaaennesn 


GLOBAL BROADCAST SERVICE (GBS) 


@Peprawenmaesseeeee see eet oaeaeudcseeeaeepspee eee vueneeet@manvneauuenenrpeeepnna 


A. BN TROD CMON coos saunas acaecacasoatenaa Senta suiegestenualsauaneweumetieatntone 
B. HISTORY AND CONCEPT DEVELOPMENT .........0000000 cc ceeeeeeeeeeee 
1. Direct Broadcast Service (DBS) .............c ccc ceeceeeeceeeeeeeseneeee 
2. Global Broadcast Service (GBS) ...........0...ccccceesesesseseeeeecceeseeceeeees 


Vil 





C. INDHAL-GBS: DE SIGIN :ccastesiict.tesssetzucnscdinitearnerertaramdan ainda ees 28 
1. SBS ShdaCe SCOMENE: tcc oieteteecyetee eet ede eteeiadon 29 

2. Broadcast Management Centels ..................ccccceeeeeeeeeeeeereneeeeeae ens 31 

D. CONCLUSIONS ................c::2cccccrccsssceseesssees eres ntataaniete gaat eesatnaigs 33 
DMS BROADCAST OVER GBS ............0..ccccssssccccccecebacccceascenecneesenneseneconeeesessaas 35 
A: INTRODUCTION icc cers cicastemleniesetatereeteeen cade 35 
B. ENABLING TECHNOLOGIES. ..........cccccccsssssscccccnenerceseccrecseecreceeseeeennecess 37 
1. IPv6 and Anycast Addressing .................cccseeeeeeeeeeeeeeeeeeseeaneneenens 37 

2. jt (eo) 0) | coh | made Ree Erne POURS Pave Orne RNS e nner Eee te err orn eer ere 40 

C. GETTING A DMS MESSAGE TO A TACTICAL UNIT ....0.... ee 42 
A: UA PICISIAG aise vicccasvae ieeeer ta eteerees encoun ae aicotceeeaecennasens 42 

2 Unit Underway ...... ia Dtdclad ceirid catia dtiset sola Buutecn aces uaedaneeanaenaeaasrac ates 43 

3. DMS Broadcast to an Embarked Unit .............. ce eeeeeeeeeeen eens 47 

4 Shipboard Message FIOW ................ccccceeeceeeecceeeeeeeeeeeeuseeseneeeseenees 48 

D. DOCTRINAL ASPECTS: SMART PUSH, USER PULL ...........0.......0... 49 
iP Specific Times to Transmit Messages ............ eee cs ceeeeeeeeeeeeees 50 

2. RECEIDE GONMMIGNONS sicndccsuiireseiatoseviedtan eres ereisaievonnontiaedduitiies 51 

3. Routing Instructions for High Priority Messages ..................0.. 51 

4. Storage of Messages With Certain Header Data ....................... 52 

E. ADVANTAGES 0... eccccccscseeseseseseceeeeeeneeneeee eee eee 52 
Ts IDOI eo icoate dices acheter sec haste oie Gageeaheoeceieeastie tas simoneees 52 

Pe: PETTOMMAN CO sais cesses esaeade vce nos cseceigeweandeaduinenrcinedi sane homaetnag: 53 

3. SCTE ests etorc eatin rears tan gies baer teceetame seanaenese 53 

4. Relief of MILSATCOM Burdens ..................:cccseeeeeeeeeeeeeeeeeeeunee eens 53 

5 Near and Long-Term Utility 0.0000... eeeeeeeeeeeeeeeeeeeeaneeeees 54 

Re IVETE ONS soca sea nceccateteaea nica sce coes soe ecient eee aeteet cnet ie 54 
1 Receipt Acknowledgment ................ccccc:sseeeceeeeeeeeeseeesteneeeeraeeneees 54 

2 PO as tea sat ase rostrata anes eornste stage gate aan er aac olasncteenaeretun tes aaua es 54 

G. CONGEPT- SUMMARY. sects ccecoracetecticcctseetcceneet Acaleeatenenneenrece 55 


vill 








V. RECOMMENDATIONS AND CONCLUSIONS .........00000 i eceeeeeereeeeeneees 57 
A. NEAR-TERM RECOMMENDATIONS ...0.. 0... ccs eeecccesenenesenneeee 57 
1. Infrastructure: World-Wide GBS Coverage .................cccccccceeees 58 
Z. Accelerated Development / Fielding Of CMTP. ............000..0... 58 
3. Application of IPv6 on the DISN ...0...... eee ceeccceeneecaeeeees 59 
4. Application of Mobile IP Concept..........00 ce eeecceseceeeseeees 59 
9. NCTAMS as DMS and GBS Theater Management Centers ....... 59 
B. LONG-TERM RECOMMENDATIONS ...0.... oo. ccceccccceesesccececeseseeaneeeens 60 
C. AREAS REQUIRING FURTHER STUDY ........ oc eeecceeseeseeeseeeeeees 61 
D. GF Bj (6) Bi oo) | | SS nee ner oe Pe Cae ee AE ve ne eR EER ET Ere 63 
APPENDIX A. OPEN SYSTEMS INTERCONNECTION (OSI) 
REFERENCE MODEL ................ eee aa bacon tote scueiencesaseeetee: 65 
APPENDIX B. X.400 ENVIRONMENTS, COMPONENTS AND 
INTERFACE. PROTOCOES aitiicessisisticecstscctsivensdtcvdcenceusbaerevtad: saneanidaiies 67 
APPENDIX C. DATA THROUGHPUT COMPARISONS OF 
VARIOUS SYSTEMS s.sisctisctdeciisestial daiectosaatsanstasalaosnetinateesbanssceataiatadien 69 
TLDS Bik © | ae leat 5 cl | cat ene POR eC TESTE Ore Pe 71 
INTHAL DIS TRIBUTIONIENS Vi ccscccpceci ce oreschecacauecercccsctaovnneanidatectunn dt theca inbeunl acecoinalstetnes 73 





LIST OF FIGURES 


1. DDN TO DISN Transitional Relationships ........0..000.ccceeccccccessecescecccssseessescsceeeeesees 5 
2. Shipboard Fleet Broadcast Subsystem 000.000... ec cccecccssccsecsesecertesesecececeeeeccesee, 21 
3. Commercial DBS System Block Diagram .0.0.....0 cc ccecccccccceccccecececcecereeececeseeeecccccce. 27 
4. GBS System Block Diagram .........0.0c ccc cece ecccceceeceeccseeeceseaceseacseceseneeeeececsesesecee 30 
5. NCTAMS as a GBS Theater Broadcast Management Center .............cccccccccccccee 33 
6. Anycast IP Address Scheme .0..........ccccccccccccecceceseeesteseeceueueecscuctauvieseeceeeeceececeesees 39 
7. Mobile IP Routing Concept ........c coc cecccccesssssesceccecertestrtsiseesececeseetetttttisesesesses. 41 
8. Proposed Mobile IP/Anycast Routing Scheme 0.0.0... .ccccccccccceccccsececcceceececceseccesescees 45 
9. Shipboard Data/Message FIOW 0.0.0.0... cece ceceeccessccecseceeesssssesstessessseseteteeeeesteees 49 


. Shipboard Data/Message Flow 


Xi 











LIST OF TABLES 


1. DMS Speed Of Service Comparisons 


steoew eee eer ese eee ene acne ee ean en eee ewer eee nee ee eee eee ee ee enter eee eee 


coe eee we ee sees reer eee rae eee eee eee tet eee doe rereneeeneeeeoses 


2. GBS-Capable UFO Performance Summary 


Xili 








DoN 
EBCDIC 
EDAC 
EHF 
email 
EMCON 
FEC 
FLTBCST 


MHz 
MILSATCOM 


LIST OF ACRONYMS AND/OR ABBREVIATIONS 


Allied Communications Policy 
Asynchronous Transfer Mode 
Automated Digital Network 

Bit Error Rate 

Broadcast Management Center 
(Theater Unified) Commander In Chief 
Connectionless Message Transport Protocol 
Continental United States 

Concept Of Operations 

Direct Broadcast Service 

Distributed Communications Processor 
Defense Data Network 

Defense Information Systems Agency 
Defense Information Systems Network 
Defense Message System 

Department of Defense 

Department of the Navy 

Extended Binary Coded Decimal Interchange Code 
Error Detection and Correction 
Extremely High Frequency 

electronic mail 

Emissions Control 

Forward Error Correction 

Fleet Broadcast 

Global Broadcast Service 

Global Command and Control System 
General Service (message) 

Giga-Hertz 

Government Open Systems Interconnect Profile 
High Frequency 

Internet Protocol 

Internet Protocol version 6 

Integrated Services Digital Network 
International Telecommunications Union 
Joint Army, Navy, Air Force Publication 
Joint Chiefs of Staff 

Joint Warrior Interoperability Demonstration 
Local Area Network 

Atlantic (ocean) 

Multi-Function Interpreter 

Message Handling System 

Mega-Hertz 

Military Satellite Communication 


XV 





MISSI 
MNS 

_ MPEG 
MTA 

MTS | 
NAVCOMPARS 
NAVCOMSTA 
NAVMACS 
NCP 
NCTAMS 
NIPRNET 
NRO 

NSA 

ORD 

OSI 

PAC 
QPSK 

SCl 

SHF 
SIPRNET 
SMTP 
SPAWAR 
TAC-3 
TACINTEL 
TCP 

TDM 

TS 

UA 

UDP 

UFO 

UHF 
USMTF 
USSB 

VLF 

WAN 





Multilevel Information Systems Security Initiative 
Mission Need Statement 

Moving Pictures Expert Group 

Message Transfer Agent 

Message Transfer System 

Navy Communications Processing and Routing System 
Naval Communications Station 

Naval Automated Communications System 

Navy Communications Processing and Routing System 
Naval Computer and Telecommunications Area Master Station 
Non-classified Internet Protocol Routed Network 
National Reconnaissance Office 

National Security Agency 

Operational Requirements Document 

Open Systems Interconnection 

Pacific (ocean) 

Quadrature-Phase Shift Keying 

Special Compartment Information 

Super High Frequency 

Secret Internet Protocol Routed Network 

Simple Mail Transport Protocol 

Space and Naval Warfare Systems Command 
Tactical Advanced Computer (version) 3 

Tactical Intelligence 

Transmission Control Protocol 

Time Division Multiplex 

Top Secret 

User Agent 

User Datagram Protocol! 

UHF Follow-On (satellite) 

Ultra High Frequency 

United States Message Text Format 

United States Satellite Broadcasting KCorporauien) 
Very Low Frequency a 
Wide Area Network 


Xvi 








ACKNOWLEDGMENT 


The author would like to acknowledge the following persons for their guidance, 
support and patience during the completion of this thesis: 


LCDR Kathleen Bryant, SPAWAR PMW 172-D3E 
Mr. Sheldon Arey, MITRE Corp. 
Dr. Roy Axford, NCCOSC RDTE DIV 841 
Mr. Bruce Miller, NTC 


Xvil 








XViil 











EXECUTIVE SUMMARY 


DoD messaging is moving to the Defense Message System (DMS). DMS is a 
hardware, software and information management solution designed to meet all DoD 
messaging requirements and allow for interoperable electronic messaging. In a most 
basic sense, DMS can be viewed as the set of components via which a DoD-wide 
electronic mail (email) service will be established. Military messaging requirements, 
met in the past by service-specific (and often incompatible) systems, will now be 
incorporated into a DoD-wide multimedia email environment. Beyond the changes in 
messaging standards, DMS alters the way DoD conducts its messaging and over what 
links these new messages are passed. DoD DMS transition efforts are aimed at 
complete replacement of the current Automated Digital Network (AUTODIN) 
message-switched network by the year 2000. 

However, while shore-based users can rely on such infrastructure technologies 
as Integrated Services Digital Network (ISDN), Asynchronous Transfer Mode (ATM), 
commercially-standardized network protocols and high-throughput physical links to 
increase their DMS performance and connectivity, these same technologies have not 
effectively been applied at the mobile, tactical level. Furthermore, the Navy must 
contend with DMS connectivity to highly mobile subscribers, who also function as the 
basic element of the naval operational force, namely ships. Complicating the Navy's 
DMS implementation efforts is the fact that tactical units must often, due to bandwidth 
limitations and operational security (i.e. Emissions Control - EMCON), commit solely to 


a “receive only" communication link known as the Fleet Broadcast. It is expected that a 


xix 








broadcast capability must be maintained by the Navy's emerging DMS infrastructure. 
However, the Navy's Fleet Broadcast subsystem Is ill-equipped to handle DMS 
message traffic. Increased throughput requirements, incompatible protocols, security 
concerns and system management issues must be addressed prior to effective DMS 
connectivity in a broadcast mode. Many technical and managerial aspects of the Fleet 
Broadcast must be modernized if it is to become a seamless extension of the DMS 
infrastructure into the tactical environment. Current proposal for resolving the 
limitations of applying DMS over broadcast links call for the translation of the DMS 
message back to an AUTODIN format prior to transmission over all MILSATCOM 


communication systems, both duplex and broadcast. This is admittedly a short-term 


~ golution. 


High data-rate direct broadcast services, recently perfected by civilian industry, 
represent a unique and timely opportunity for the US military to vastly improve its data 
dissemination architecture. In an attempt to effectively apply this emerging technology, 
the US military ts Beyeroping a new satellite-based data dissemination system, based 
on similar commercial nebiieds known as the Global Broadcast Service (GBS). The 
application of GBS as a "next generation" Fleet Broadcast offers an expansive leap in 
tactical broadcast communication capability. Furthermore, this broadcast technology 
can be effectively adapted to the DMS architecture. In this manner, not only is the 
Navy's message broadcast capability expanded, but the overall load on duplex 

MILSATCOM systems is reduced. 


DMS broadcast to the tactical environment via GBS and the integration of this 


capability into the DISN requires the application of relatively new network addressing 














and mobile user routing protocols. Adaptation of the current DMS messaging protocols 
is also required. The proposed communications architecture provides for a high 
data-rate message broadcast system, capable of carrying DMS traffic to mobile units. 

_ The proposed system offers a near-term tactical DMS utility while more robust duplex 
links are developed. It also identifies the frame-work for a long-term DMS "Fleet _ 
Broadcast" link. 

Ultimately, DMS will be implemented in all DoD environments: tactical, strategic, 
fixed and mobile. However, while DMS efforts are aimed at providing multimedia 
messaging capabilities, the networks used to pass these messages are not being 
expanded to meet the new requirements. This thesis attempts to present one possible 
method of integrating the DMS and GBS systems. This effort is undertaken in order to 
explore how the DMS messaging capability can be extended to the mobile, tactical user 
via a new, more robust broadcast subsystem. While a duplex DMS connectivity to 
tactical units is certainly essential, this thesis focuses on an architecture and concept of 


operations for a high data-rate, DMS capable broadcast system. 








|. INTRODUCTION AND PROBLEM OUTLINE 


A. THE DMS CONCEPT 

The Department of Defense (DoD) is currently transitioning from 
service-specific (and often incompatible) messaging systems to the Defense 
Message System (DMS). The DMS complies with the X.400/X.500 international 
Standards for digitally switched message’ (non-voice) traffic. DMS is a hardware, 
software and information management solution designed to meet all DoD 
messaging requirements and allow for interoperable electronic messaging. Ina 
most basic sense, DMS can be viewed as the set of components via which a 
DoD-wide electronic mail (email) service will be established. Ultimately, DMS will 
be implemented in all DoD environments: tactical, strategic, fixed and mobile. 
Basic DMS requirements, as outlined by the Assistant Secretary of Defense for 
C3l, include: [Ref. 1] 

- support for exchange of electronic messaging at all classification levels 

- maintain a high level of reliability and availability 


- interoperate with current messaging systems until fully implemented 


- field a single system that supports both formal (organizational) and 
informal (individual) message communications. 


DMS long-term goals include the phasing out of existing messaging systems, the 
automated extension of email services to the end user, and increased 


messaging connectivity throughout DoD with expanded capabilities such as text, 
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~ Throughout this thesis Sidesiigs traffic" refers to non-voice organizational 
communications of an official nature or of general operational interest. 


1 








video, images and pre-recorded voice. The DoD's ultimate DMS goal, as stated 
on the DMS World Wide Web home page, Is a secure, accountable, reliable 


writer-to-reader messaging system for the warfighter at a reduced cost. 


1. Basic X.400/X.500 Concepts 


An in-depth review of all DMS functions, components and structure is not 
undertaken in this thesis*. However, some specific aspects and technologies 
which form the basis of DMS and the X.400/X.500 email protocols are reviewed 
in the following subsections. 

DMS is based on the 1988 X.400 email protocol and the Open Systems 
Interconnection (OSI) network model, which divides the various processes 
involved in electronic data transfer into seven distinct layers (refer to Appendix 
A). These layers are each responsible for specific aspects of data manipulation 


and network interaction. 


a. X.400 


The X.400 email protocol is composed of three environments (refer 
to Appendix B). The inner-most environment is the mail transfer system (MTS) 
which provides the basic service of moving messages from one place to another. 
It consists of Message Transfer Agents (MTAs) that communicate with each 
other via an application protocol known as P1. The lower-level network and 


transport protocols used between MTAs are not specified by X.400. P1 assumes 


2 


A comprehensive DMS technical overview can be found in Ref. [3]. 
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the presence of these lower-level protocols, but makes little a on them; 
this allows X.400 packets to be carried over physical links by various routing and 
transport protocols. This lack of reliance on lower protocols is beneficial when 
applied to the vast majority of networks, which are bee on duplex connectivity; 
but causes problems when applied to a simplex (one-way) communication link. 

The second environment, called the message handling system 
(MHS), incorporates user agents (UA) which act as the user's direct email 
interface mechanism. A UA allows the user to create, edit, send, receive and 
view X.400 email messages. Personal computers are the most common UA 
implementation. Several UAs can be connected to a single MTA. The protocols 
used to connect UAs to MTAs are known as P3/P7. The final, outer-most, layer 
incorporates the users and the type of network system environment (e.g., single 
unit, squadron, organization) over which the MHS is implemented. 

Although DMS will maintain the DoD's five levels of priority for 
message delivery, these levels will be mapped to the three precedence levels 
inherent in X.400 for actual transport. Table 1 compares the speed of delivery 


service for X.400 and the current DoD message precedence and delivery criteria. 
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Table 1. DMS Speed of Service Comparisons. After Ref [2]. 







b. X.500 


X.400 addresses are composed of long attribute and value Strings 
(e.g., country: USA; enterprise: US Navy, organization: CINCLANTFLT, 
suborganization: Second Fleet, unit: USS SHIP, title: CO)°*. Because these 
strings are difficult to remember, a user-accessible central store of X.400 
addresses was required. This address database is implemented with 
international standards known as the X.500 series data store protocols. These 
protocols allow users to query a distributed directory for any data they require 


(e.g., X.400 email addresses and/or demographic data). 











° As an example, the Simple Mail Transfer Protocol (SMTP) used extensively 


on the commercial Internet uses a simple string of domain, subnetwork, network 
and user identifiers, where the user's identifying script is separated from the 
network addresses by an"@". An SMTP address looks like: 
user@subnet.network.domain 











2. DMS Role Within the DISN 


Beyond the changes in messaging standards, DMS alters the way DoD 
conducts its messaging and over what links these new messages are passed. 
Figure 1 depicts the transitional relationships between the current Defense Data 
Network (DDN) inicitaieiias subsystems and the proposed integrated _ 
communication architecture commonly referred to as the Defense Information 
Systems Network (DISN). DMS will act as the message traffic component of the 
DISN. DoD DMS transition efforts are aimed at complete replacement of the 
current Automated Digital Network (AUTODIN) message-switched network by 
the year 2000 [Ref. 2]. All DISN (and therefore DMS) transition efforts are 
coordinated by the Defense Information Systems Agency (DISA). Each service 
maintains a DMS Program Office chartered to implement DMS transition 


components. 


PRE 1992 TRANSITION PERIOD: 1992-1999 GOAL FOR 2000 


DDN | DISN 


| Unclassified But Sensitive Data 
MILNET NIPRNET 
SECRET Data 


all operational & personal message traffic — 


AUTODIN AUTODIN / DMS DMS 





Figure 1. DDN to DISN Transitional Relationships. After Ref [3]. 











3. DMS and the US Navy 


There are approximately 11,235 communication sites‘ in the US Navy, 
distributed over 273 land-based commands and 369 ships. Additionally, the 
Navy provides communication support to approximately 390 non-DoN 
organizations [Ref. 4]. There is no official documentation of the amount of intra- 
and inter-DoN email communications over the commercial Internet. However. a 
1994 study indicated that at least 18 different types of proprietary email systems 
are in operation throughout DoN activities and commands [Ref. 4]. The Navy's 
DMS solution proposes to standardize these systems and provide email 
connectivity to both shore and sea-based operators with the same elements of 
service denoted for all DMS users. However, while shore-based users can rely 
on such infrastructure technologies as ISDN (Integrated Services Digital 
Network), ATM (Asynchronous Transfer Mode), commercially standardized 
protocols and high-throughput physical links ss increase their DMS performance 
and connectivity, these same technologies have not effectively been applied at 
the mobile, tactical level. 

Furthermore, the Navy must contend with DMS connectivity to highly 
mobile subscribers, who also function as the basic element of the naval 


operational force, namely ships. Bandwidth limitation, both at the receive station 


4 


Communication "site" is defined here as a dedicated communication center, 
transmit/receive facility or station. Theoretically, DMS expands this definition to 
include the individual email user. 











(ship) and relay satellite, is by far the most constraining factor in the full 
implementation of DMS connectivity to all US Navy subscribers [Ref. 4]. 

The Navy must also, in its tactical DMS implementation efforts, meet 
several required operational messaging characteristics, defined by DISA, which 
denote the base performance standards expected of all DMS implementation 


efforts within DoD [Ref. 5]. They include: 


- Maintain a probability of message loss less than 1 out of 100 million 

- Provide for changing traffic loads, accommodate peak traffic volumes in 
times of crises (150% of peacetime rates) and war (200% of 
peacetime rates) 

- Ensure writer-to-reader system availability of at least 98.5% 

- Maintain 25% system growth allowance 

- Store at least 10 days of organizational messages 


- Maintain storage capacity for 30 days of audit information 


- Guarantee organizational message delivery of at least 99.99%. 


Complicating the Navy's DMS implementation efforts is the fact that 
tactical units must often, due to bandwidth limitations and operational security 
(i.e., Emissions Control - EMCON), commit solely to a "receive only" 
communication network known as the Fleet Broadcast (FLTBCST). Itis 
expected that a broadcast capability must be maintained by the Navy's emerging 
DMS infrastructure. The technical and information management details of the 


Navy's current Fleet Broadcast system are reviewed in Chapter II of this thesis. 





B. DMS IN THE CURRENT NAVY BROADCAST ENVIRONMENT 

_ New messaging architectures and higher bandwidth transmission 
subsystems are the key to the world-wide communication infrastructure outlined 
in the Navy's COPERNICUS concept. DMS is viewed by its proponents as a 
critical springboard for future application of information management 
technologies within the DoN and DoD. Moreover, any new information system 
demands a review of how to best organize, manage and disseminate that 
information. This is especially true of DMS, where not only is equipment to be 
replaced, but where the entire concept of how the DoD accomplishes its 
message communications will be altered. 

Current Navy fleet broadcast architectures cannot meet the new DMS 
requirements. Increased throughput requirements, incompatible protocols, 
security concerns and system management issues must be addressed prior to 
effective DMS connectivity in a broadcast mode. These points are detailed 


below. 


1. Bandwidth Limitations 


The primary causes of communication backlogs within the current 
FLTBCST are the slow transmission rates of the satellite subsystems (maximum: 
9600 bps). Average Navy message size was determined in 1990 to be 2,544 
bytes [Ref. 7]. DMS will, without doubt, increase average message size due to: 

- the higher overhead associated with the X.400 protocols 


-an expanded messaging capability (e.g., multimedia attachments) 
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- overhead added by application of security protocols 

- other reasons presented in detail later in this thesis. 

The ease of use and widespread application of DMS can also be 
expected to increase the number of messages sent between users, in much the 
Same manner as the recent explosion of email use over the commercial Internet. 
The current throughput capabilities (measured in bps) of the DoD's Military 
Satellite Communication (MILSATCOM) systems are far less than what is 
required for effective DMS connectivity to tactical units. 

The bandwidth expansion capacity of current shipboard systems are 
stifled, mostly due to limitations in receive antenna size. Use of commercial C 
and Ku-band satellites, with associated large (2-3 meter) receive antennas may 
alleviate bandwidth constraints on large platforms such as aircraft carriers and 
amphibious ships, but it does not address the needs of smaller escorts and 
submarines with their limited antenna support structures. Some evolving 
antenna technologies, such as phased array antennas, may well alleviate the 
limited antenna space concerns on smaller ships, but widespread application of 
these technologies will not occur in the near term. 

Smaller, higher bandwidth, satellite transmission systems must be 
examined and applied to the Navy's DMS tactical environment as message size 
and traffic load increase. When variation in antenna size and receiver sensitivity 
is limited, increased data throughput can be obtained only by using higher 


frequency bands, increasing satellite downlink transmission power or application 








of higher data compression ratios. A recently developed broadcast satellite 


system, which meets these demands, is the focus of Chapter III of this thesis. 


2. Protocol Iincompatibilities 


As previously presented, DMS is based on the 1988 X.400 email protocol 
and the Open Systems Interconnection (OSI) model (refer to Appendix A). 
Layers 1 through 3 involve the physical transport, addressing and routing of the 
datagrams, while layers 4 through 7 (of which X.400 is a part) are responsible for 
higher levels of datagram sequencing, error detection/correction, formatting and 
presentation to the user. DMS messages, although formatted with the X.400 
protocol, are predominately carried over the Transmission Control Protocol / 
Internet Protocol (TCP/IP) based NIPRNET. TCPIIP is a set of transport, 
addressing and routing protocols (equivalent to OSI layers 3-4) developed by 
DoD for use on the Internet. They remain the most common set of network 
interconnection protocols on the Internet. 

The general benefit of the OSI model is a strict division of networking 
responsibilities. Each layer is wholly responsible for very specific aspects of data 
manipulation and network interaction. Each layer interacts only with the layer 
immediately below and above it. However, when a network connection is made 
between two nodes, each layer located at one end-node also communicates 
(exchanges specific data) with its counter-part on the other end node (true for all 


layers above the network layer). This ability to establish a duplex link and 


exchange data back and forth between nodes is known as connection-oriented 
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connectivity. The connection-oriented requirements inherent in the application of 


X.400 over TCP/IP networks increases the number of transmitted data bits 


required to affect a message transfer. 


a. TCP/IP 


The Internet Protocol (IP) is designed for use in interconnected 
computer communication networks. IP provides for transmitting blocks of data, 
called datagrams, from sources to destinations, where sources and destinations 


are identified by fixed-length numerical addresses. IP also provides for 


fragmentation and reassembly of long datagrams. Each datagram is treated as — 


an independent entity unrelated to any other datagram. IP does not provide 
reliable communications. There are no acknowledgments and there is no error 
correction for datagrams, only a header checksum. There is no facility for the 
retransmission of lost datagrams or for controlling the flow of datagrams. 

All reliability, error control, retransmission and sequencing actions 
are carried out by the next higher layer in this model, known as the Transmission 
Control Protocol (TCP). TCP insures that the higher application layers receive 
datagrams that are error-free and in correct sequence. However, TCP can only 
operate effectively in a connection-oriented network environment. This means 
that TCP expects the destination node to send acknowledgments whenever it 
successfully receives a datagram. All datagrams (e.g., X.400 message packets) 
must therefore travel along a circuit path in which both the sending node and the 


intended receiving node can communicate with each other. Basically, a two-way 
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data exchange session must be established and maintained between the 


sending node and the receiving node in order for datagrams to be passed. 


b. §X.400/TCP and Simplex Links 


During an X.400 message transfer session, both the P1 protocol 
and the TCP layer of the originating node communicate directly with their 
respective counterparts on the recipient node. Basically, the originating MTA's 
P1 expects to receive acknowledgment from the recipient MTA prior to and 
during message transfer. These acknowledgment datagrams are in addition to 
the retransmission requests commonly sent back and forth between the TCP 
layers. This duplication of effort does not pose immediate concern if the two 
network nodes maintain a duplex connectivity. In that case, the two protocols 
(P1 and TCP) can each request and receive individual acknowledgments. 
However, this duplication of effort does add to link congestion since an 
undeterminable number of acknowledgment packets are required to affect a 
datagram transfer. Furthermore, this duplication of effort also presents problems 
when applied to simplex links where the protocols cannot exchange data. 
solutions which satisfy the acknowledgment needs of both the P1 and the 
transport layer (TCP) must be incorporated to effect a successful message 
transaction over a broadcast link. 

The need to satisfy the acknowledgment requirements of both the 
P1 and TCP protocols represents the primary hindrance to the application of 


DMS in "connectionless" network architectures, of which (simplex) broadcast 
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communications are a part. In order to satisfy the needs of the ee layer 
over a simplex link, (e.g., over Fleet Broadcast) datagrams must contain both 
packet sequence data and imbedded error detection and correction (EDAC) 
schemes, known as forward error correction (FEC); both require additional data 
bits. These additional bits are critical since the receiving node (e.g., a ship's 
MTA) cannot immediately send back requests for packet retransmission if it finds 
an error or fails to receive a packet. However, with DMS, the acknowledgment 
demands of the originating MTA's P1 must also be met, since it expects to 


interact (exchange data) directly with the P1 layer of the receiving MTA.° 


c Mobile User Connectivity 


The DISN lacks a capability which is paramount to successful, 
seamless integration of US Navy tactical units into its network. Specifically, 
TCP/IP, as presently incorporated by the NIPRNET, cannot effectively route 
datagrams to units unless they maintain a network (DISN) interface via the same 
network host. The IP protocol ties the physical location of a node with its 
network connection. If a node leaves its network and then regains connectivity 
via another host interface (e.g., a user leaves their home office and wishes to 
receive all their email via a network in another city), it must be assigned a new IP 
address by the new network interface host. This new IP address must be 


updated by all network routers and nodes in order for the mobile node to 
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This need for application-layer connectivity is not unique to DMS. Most 
applications designed for use on networks rely on duplex links over which to 
coordinate information transfer. 
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continue receiving datagrams. In Navy terms, a ship transitioning from the 
Atlantic to the Mediterranean must be assigned a completely new IP address. 
This new address must then be broadcast to all DISN users and routers before 
seamless re-routing of traffic to the ship can occur. Message Originators which 
use the ship's old IP address will be unable to effect a successful connectivity 
with it. If IP addresses shande often and new address updates are not quick 
enough, then network connectivity at the routing (IP) layer can easily be lost. 
The scalability and seamless integration of such a mobile-user capability into a 


network as large as the DISN is not a trivial concern. 


3. Security Concerns 


The DISN, unlike AUTODIN, is not based on a secure network 
infrastructure. The new DISN packet-switched architecture is divided between 
two sublinks: the NIPRNET and the SIPRNET (Secure Internet Protocol Routed 
Network, see Figure 1). DMS messages will be transported over the NIPRNET. 
Instead of encrypted links, which now dominate the AUTODIN messaging 
architecture, DMS will rely on a variety of security formats whose purpose is the 
security and encryption of the message itself, vice the physical link over which it 
travels. The National Security Agency's (NSA) MISSI (Multilevel Information 
systems Security Initiative) program is responsible for DMS message security 
products and implementation. A primary concern is the loss of security during 
message processing and routing. MISSl-encrypted DMS messages (multimedia 


attachments are also encrypted) must be delivered in unaltered form to the 
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reader. MISSI security also allows for authentication of message sender via a 
digital signature which is electronically "stamped" on the message. In the 
context of this thesis, these important security features are viewed as even more 


bits which must be added to the DMS message prior to transmission. 


4. Proposed solutions 


There are currently two proposals for resolving the imitations of applying 
DMS over broadcast links. The first method (and the one currently being 
examined for Navy tactical DMS implementation) calls for translating the 
X.400/DMS message back to an AUTODIN format prior to transmission over all 
MILSATCOM communication systems, both duplex and broadcast. The key 
limitation of this proposal is the MILSATCOM bandwidth constraints already 
discussed. Furthermore, this proposal violates the basic DMS elements of 
service for the tactical users. It does, however, offer a near-term solution to the 
protocol, security and mobility issues. The second (longer-term) proposal calls 
for a direct DMS broadcast capability which involves an alteration of the P1 
protocol. This new protocol, the Connectionless Message Transport Protocol or 
CMITP, will allow the X.400 application to operate over a simplex link. However, 
it does not address the lower-layer routing and transport concerns. A more 
detailed review of these proposals and their limitations is undertaken in Chapter 


IV of this thesis. 
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C. THESIS SCOPE 


Military messaging requirements, met in the past by service-specific 
systems, will now be incorporated into a new DoD-wide email environment. 
DISA has been appointed the DMS management agent and as such is 
responsible for the integration and interoperability of all DMS subsystems. A 
decentralized approach to subsystem integration and compatibility has been 
chosen. Each service has been tasked only to find solutions to its particular 
messaging needs, with all proposed DMS architectures containing a 
standardized interface link to the DISN. The interior details of the DISN are yet 
to be finalized and are seen as beyond the scope of the service system 
developer's requirements. Key to the effective integration of this distributed, 
systems engineering process is the proper implementation of accepted interface 
protocols and formats by all concerned. 

Tactical DMS implementations must deal with more complex connectivity 
hurdles than shore-based systems, as outlined in the previous sections. The 
interface connection from the tactical user to the common DISN cannot be 
reduced to an electronic line pointing to a "cloud". Realistic answers must be 
outlined and management issues resolved. 

While a duplex DMS connectivity to tactical units is certainly essential, this 
thesis focuses on a specific technical solution to the broadcast DMS problem. 


An architecture and concept of operations for a high data-rate, DMS capable 
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“next generation" Fleet Broadcast System is the central goal of this thesis. 


Options for management and implementation of that system are also outlined. 
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ll. USN FLEET BROADCAST 


The US Navy's broadcast messaging system is known as the Fleet 
Broadcast (FLTBCST). The current FLTBCST subsystem is an automated, 
simplex (shore-to-ship) service which uses low-rate MILSATCOM transponders 
to broadcast Top Secret and below General Service (GENSER) message traffic 
to ships and other mobile units. Messages destined for broadcast are 
automatically prioritized, formatted, stored, backlogged and routed at Naval 
Computer and Telecommunications Area Master Stations (NCTAMS) by the 
Navy Communications Processing and Routing System (NAVCOMPARS or 
NCP). NAVCOMPARS is based on early 1970's mainframe technology and 


integrates the AUTODIN with the operational fleet communication subsystems. 


A. NCTAMS PROCESSING 


The Navy operates four NCTAMS: Norfolk, Virginia (LANT); Bagnoli, Italy 
(MED); Wahiawa, Hawaii (EASTPAC), and Finegayan, Guam (WESTPAC). 
These stations provide satellite and HF connectivity to fleet users. Theater 
Unified Commanders (CINCs) maintain operational control of their NCTAMS and 
the content of the Fleet Broadcast. NCTAMS currently maintain an interface to 
the DISN as well as the message-switched AUTODIN and circuit-switched voice 
subsystems. The HF broadcast capability serves as a back-up method of 


message dissemination. 
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1. Message Processing 


Messages received by the NCP are first recorded in their original format 
on hard disk memory. The message is then converted to a common format, 8 bit 
Extended Binary Coded Decimal Interchange Code (EBCDIC), for processing. 
The NCP system analyzes the message for priority, suspected duplication, 
routing indicator and distribution assignment. Transmission scheduling and 
queuing are also automated, with each message processed in a first-in, first-out 
manner, based on precedence /evel. Human interface and control is provided 
via a command line terminal, where system monitoring, testing and manual 
message injection is performed. The processed message is again recorded on 
hard disk prior to transmission. A 1985 Space and Naval Warfare Systems 
Command report found that an average of 12,000 broadcast messages are 
processed by each NCTAMS daily, while average daily broadcast traffic received 


by a major combatant ship is less than 5000 messages [Ref. 6]. 


2. Message Transmission 


The Fleet Broadcast is transmitted to tactical users via three frequency 
bands: SHF/UHF (satellite links), HF and VLF. The satellite system, controlled at 
NCTAMS sites, uses an SHF direct sequence-spread spectrum uplink. The 
signal is downconverted by the satellite to the UHF band and then downlinked to 
small omni-directional antennas onboard ships. The broadcast is composed of 


16 7Sbps subchannels which are time-division multiplexed (TDM) into a 
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composite 1200bps data stream: eleven general service (GENSER) traffic 
channels, two weather channels, two Special Compartmented Information (SCI) 
level Tactical Intelligence (TACINTEL) channels and one system synchronization 
channel. Once received onboard ships, the UHF downlink is demoduiaiss and 
demultiplexed; GENSER and weather subchannels are routed to the ship's 
message processor, known as the NAVMACS (Naval Automated 
Communications System), while the intelligence traffic is forwarded to the ship's 
TACINTEL processors and teletypes. 

FLTBCST messages conform to a variety of formats including: US 
Message Text Format (USMTF), Joint Army, Navy, Air Force Publication 
standard (JANAP) 128 , and the Allied Communications Policy (ACP) standard 
121/127. Figure 2 depicts a simple overview of a ship's current FLTBCST 


communication subsystem, its major components and their integration. 


MILSATCOM Satellite 
— -= 2 channels for 
INTELLIGENCE DATA 


@ 75bps each 


UHF Downlink TACINTEL TELETYPE 


2 channels for 
SHIPBOARD 

RECEIVERS CRYPTO WEATHER DATA TELETYPE 
SHF Uplink UHF/HF EQUIP. Dps eac PRINTERS 


(Spread Spectrum) 1 time synchronization channel 


From NCTAMS on Shore 
NAVMACS TELETYPE 
PROCESSOR PRINTERs 


channels for 


GENSER TRAFFIC @ 75bps each 





Figure 2. Shipboard Fleet Broadcast Subsystem. After Ref [6]. 
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B. NAVCOMPARS II 


The Navy's next generation shore-based message processing system, 
NAVCOMPARS II (NCP II), incorporates a secure software operating 
environment and a distributed database architecture operating on a Tactical 
Advanced Computer-3 (TAC-3) computer. Under the NCP II architecture, 
NCTAMS internal subsystems are connected by an Ethernet (10Mbps) network 
and maintain both a Government Open Systems Interconnect Profile (GOSIP) 
and a more-widely used TCP/IP external connectivity. NCP II's TAC-3 computer 
processes messages in 8-bit ASCII format. Input messages are converted from 
their particular formats (primarily JANAP 128 and ACP 127) to 8-bit ASCII, 
processed with much the same functionality as the original NCP, then converted 
to a 5-level baudot format prior to transmission. Conversion of outbound 
messages from ASCII to baudot is accomplished by a gateway known as the 
Distributed Communications Processor (DCP). | 

All four NCTAMS will be linked via the DISN (specifically the NIPRNET). 
This NCTAMS Wide Area Network (WAN) will provide for world-wide Navy 
communications integration and synchronization, the sharing of databases, user 
location data, and fast secure routing of message traffic. Messages passed on 
this WAN are individually encrypted for security (except for header data). Initial 
installation of NCP II at the four NCTAMS sites is expected by 1996. NCP II 
should be viewed as a much needed software and hardware upgrade to the 


current Navy communication architecture, not as a change in that architecture. 
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C. FLEET BROADCAST SYSTEM LIMITATIONS 


A serious drawback to the continued use of the current Navy broadcast 
messaging network is that the NCP can process messages faster than the 
FLTBCST satellite (and HF) subsystems can transmit them. To account for the 
difference in input and output rate, NCP uses two output queues commonly 
nee to as Q1 and Q2. Q1, with a total capacity of 6,200 messages, serves 
as an accountability queue for messages while awaiting delivery to the 
transmission subsystem. Q2, with a total capacity of 10,000 messages, is a 
buffer memory store for messages auenes for transmission but not yet confirmed 
as transmitted. The primary cause of communication backlogs (excessive Q1 
queue size) within the NCP are the slow transmission rates of the satellite 
subsystems, not the processing capability of the NCP itself. 

NCP II will greatly increase the processing speed and ease the operation 
and maintenance of Navy Fleet Broadcast management, but it will not address 
the bottlenecks caused by current transmission interfaces. Since, as presented 
in Chapter |, average message size can be expected to increase under the DMS, 
a central limitation of current Navy broadcast communication networks (under an 
AUTODIN or DMS paradigm) remains the restricted throughput available over 


military satellite systems.’ 


a 


It is worth noting that this is the inverse of the modern commercial telephone 
problem. Commercial phone companies needed to develop faster switching 
systems (e.g., ATM switches) in order to keep up with the increased throughput 
offered by coaxial cable and fiber optics [Ref. 8] 


— 


A 
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Within the DMS framework, these physical ficaitations are compounded by 
the fact that X.400 connectivity was not viewed as a critical initial requirement of 
the NCP Il; therefore NCP Il will be fielded with no direct capability to accept and 
process DMS traffic. Effective application of gateways and interfaces to the 
current NCP and future NCP Il, in order to adapt a DMS capability, poses a new 
set of interoperability, cost and management issues for near-term tactical DMS 


implementation. 
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lll. GLOBAL BROADCAST SERVICE (GBS) 


A. INTRODUCTION 

Satellite reception equipment has been publicly available since 1976 when the 
first home satellite TV system was put into service in California [Ref. 9]. These early 
systems used 8-12 foot antennas to capture (often illegally) analog C-band TV 
broadcasts from national and local TV companies. At $2000-$4000 these TV "earth 
terminals" were not cheap. Furthermore, by 1990 most C-band TV signals were 
encrypted, forcing satellite TV owners to pay for decryption equipment. 

In 1982, the FCC (Federal Communications Commission) and the ITU 
(International Telecommunications Union) allocated the 12.2-12.7 GHz band for 
direct-to-home satellite broadcast use. Then in 1984, United Satellite Communication 
Inc. (USCI) implemented the first commercial direct broadcast service (DBS) to US 
consumers. This venture offered satellite TV reception from a dedicated provider whose 
signal was broadcast by a leased Canadian satellite transponder. However, USCI 
failed to attract more than 7000 customers and went bankrupt in 1985 [Ref. 9]. 

In the time since those early attempts, advances in several commercial 
technologies have made high data-rate, digital data broadcast into small, inexpensive 
receive antennas a reality. Furthermore, this new technology is directly applicable to 
the US military's modern communication needs. This chapter will review the 
development of this new data broadcast technology, its military application and current 


military initiatives within this field. 
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B. HISTORY AND CONCEPT DEVELOPMENT 


1. Direct Broadcast Service (DBS) 

In 1994, DirecTV (a Hughes subsidiary) and United States Satellite Broadcasting 
(USSB) joined forces to provide a direct broadcast service (DBS) to the continental US. 
This satellite-based multimedia service combines high bandwidth links and large area 
coverage. There are three key components to the initial success of this new 
commercial technology: 

- large selection of high-quality full digital audio and video channels (up to 200) 

- small receive antenna (18") coupled to a small receiver/decoder 

- low cost of equipment (under $700). 

The DirecTV/USSB transmission subsystem incorporates three geosynchronous 
satellites and two ground uplink sites. Input digital video and audio signals are first 
passed through MPEG (Motion Pictures Expert Group - an International Standards 
Organization entity) compression algorithms. Reed-Solomon forward error correction 
and security encoding is applied to the digital datastream prior to QPSK (Quadrature 
Phase Shift Keying) uplink modulation at 17.3-17.8 GHz. The satellite then 
downconverts the signal to the FCC approved frequencies (12.2-12.7 GHz) prior to 
broadcast. Once captured by the small receive antenna, the signal is demodulated and 
_ decoded by the home receiver and the selected channel is routed to the user's TV. 
Compression algorithms, FEC and satellite transponder saturation provide system data 
throughput of 23Mbps with a bit error rate (BER) of 107°. Figure 3 depicts a block 


diagram of the DirecTV/USSB commercial DBS system. 
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Figure 3. Commercial DBS System Block Diagram. After Ref [9]. 


a: Global Broadcast Service (GBS) 


The military application of this new high data-rate, small receive antenna 
technology is known as GBS (Global Broadcast Service). In May of 1995, the US Joint 
Chiefs of Staff issued a Joint Mission Need Statement (MNS) which delineated the 


basic operational requirements of the GBS concept. In summary, the statement called 
for [Ref. 10]: 
-a DBS-based system to provide secure simultaneous broadcast of multimedia 


information (video, data, imagery) to all approved recipients in a theater of 
operations | 


- world-wide coverage from 70°N to 70°S 


- use of commercial off-the-shelf technologies and low risk, non-developmental 
equipment 
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- integration of the GBS system to the DISN 


- security for data transmission at all classification levels from UNCLAS to SCI. 


The GBS Joint MNS was followed by a draft GBS Concept Of Operations 
(ConOps), prepared by the US Space Command in August 1995. The GBS ConOps 
details preliminary implementation concepts and information management options, but _ 
does not address any system-specific parameters or architectures. The following points 


are presented in the GBS ConOps [Ref. 11]: 


- primary interface for GBS service requests will be the GCCS (Global Command 
& Control System). 


- GBS will augment current MILSATCOM systems, relieving them of much of the 
one way data traffic they now carry. 


- GBS will incorporate a warfighter-responsive broadcast management structure 
which transmits data from CONUS uplink sites while also allowing in-theater 
(CINC-responsive) direct injection of data. 


- two modes of operation are called for: wide area coverage and steerable "spot 
beams". 


- GBS will provide three classes of tailored service: on-demand, continuous and 
periodic. 


- the GBS system will maintain interoperability with IP-based addressing 
schemes already in use by DoD. 


C. INITIAL GBS DESIGN 


In November 1995, the Joint Staff validated the need for GBS, allocated 
approximately $900M in funding and directed the Under Secretary of Defense 
(Acquisition and Technology) to establish a Joint Program Office to manage the 


program [Ref. 12]. The US Air Force was named lead agency/service for program 
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development, while the Army will formulate the GBS Operational Requirements 
Document (ORD). 

There is no single, approved system architecture for GBS. However, initial GBS 
design concepts closely follow the commercial-based DBS. Figure 4 illustrates a typical 
GBS system structure and data flow. Major differences between GBS and commercial 
DBS include the use of ATM (asynchronous transfer mode), a switching technology 
used here in a transport/transmission role, and the use of bulk encryption for obvious 
security reasons’. The GBS Space segment and ground-based information 


_ flow/mangement concepts are detailed in the following subsections. 


1. GBS Space Segment 


There were, initially, two options for implementing the GBS space segment 
(satellites and transponders): leased commercial systems and military-only systems. 
While LORAL Corporation (a Lockheed-Martin Company) and Hughes have 
DBS-capable satellites in orbit, none of the current MILSATCOM communication 
systems is optimized for GBS service [Ref. 9]. In December 1995, the Joint Staff, 
based on recommendations by the Space and Naval Warfare Systems Command 


(SPAWAR), approved plans to place GBS transponders aboard the US Navy's Ultra 
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The BER is significantly improved by means of double (concatenated) FEC 
encoding applied to the uplink signal in the form of Reed-Solomon (R-S) block encoding 
and convolutional encoding. Viterbi decoding is performed prior to decryption in order 
to reduce the error rate to a point where decryption can be done reliably. R-S decoding 
must be applied after decryption; otherwise the error-extension properties of the 
decryptor significantly degrade the improvement obtainable from R-S FEC. [Ref. 9]. 
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2 x 23 Mbps spot beams (500nm) + 
1 x 1.544 Mbps wide beam (2000 nm) 
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Figure 4. GBS System Block Diagram. After Ref [9]. 


High Frequency Follow-On (UFO) satellites. Proposals call for the SHF Fleet Broadcast 
transponders aboard UFO #8, #9 and #10 to be replaced with four GBS (EHF band) 
transponders, a modified power subsystem and improved heat dissipation structures 
| prior to launch [Ref. 11]. There are currently five UFO satellites in orbit with four others 


scheduled for launch. These modifications will give each UFO satellite: 


- two steerable GBS spot-beams (500 nautical mile diameter coverage each) 
operating at 24Mbps 7 


- one wide area (2000 nm) low-rate GBS broadcast operating at 1.544 Mbps 


- uplink accessibility from at least one (of four) NCTAMS site at all times. 


Initial GBS/UFO operational capability is slated for the first quarter of 1998, with full 
system implementation within one year. The three modified UFO satellites will satisfy 


all space segment requirements set forth by the 1995 GBS Joint Mission Need 
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Statement. Table 2 summarizes the expected performance levels of the three GBS 


capable UFOs. 





Table 2. GBS-Capable UFO Performance Summary. After Ref [1 3}. 


2. Broadcast Management Centers 


While technical parameters and required modifications have been outlined for 
the GBS space segment, there is as yet no approved plan for the development of the 
information management infrastructure or coordination guidelines for the various data 
inputs and subsequent requests for service. However, there exists within the GBS 
development community a widely-accepted concept of a Broadcast Management 


Center (BMC) which must be capable of: 


- integrating and processing ATM, non-ATM, video, imagery and weather data 


- accepting and processing requests for GBS services from users over 
MILSATCOM and land-based networks 


- maintaining data security up to the SCI level 


- communicating with other BMCs in order to coordinate the GBS world-wide. 
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The GBS concept denotes both a CONUS-based BMC/uplink facility and theater 
CINC-controlled BMCs. However, the physical location of the broadcast sites, both 
CONUS and theater, has not been finalized. The JCS decision to modify Navy UFO 
satellites for a GBS role all but mandates the use of NCTAMS as GBS uplink sites. 
However, these NCTAMS, especially the new NAVCOMPARS II equipped sites, can 
also offer excellent GBS information fusion, management, coordination and data 
exchange capabilities as well. 

NCTAMS, as previously noted, are CINC controlled communication centers 
which already gather, fuse, process and disseminate military data up to the SCI level. 
The information infrastructure and physical data links from the DISN to the warfighter 
via the NCTAMS communication hub are already in place. World-wide coordination of 
the GBS broadcast can be maintained via the DISN-based NCTAMS WAN. 
Furthermore, the open systems architecture of the NAVCOMPARS II TAC-3 computer 
system allows for easy integration of both ATM, non-ATM, video and audio 
datastreams. Requests for GBS services can be quickly processed, since NCTAMS 
currently operate the duplex systems marked for use as the warfighter's primary GBS 
service request channels. The NCTAMS currently operate within the same 
communication paradigm envisioned by the GBS concept, namely the direct 
dissemination of information and data to the warfighter. They represent the best 
method of integrating GBS services at the warfighter level without adding new 
information management layers to the theater CINCs. Figure 5 outlines how the 


internal data flow of a NCTAMS, acting as a GBS theater BMC, can be structured. 
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While NCTAMS may be well-suited as GBS theater BMCs, there remains a need 
as noted by both the GBS ConOps and MNS for a CONUS-based coordination and 
uplink facility. This site will have access to both the Atlantic and Pacific GBS satellites, 
while maintaining a centralized management capability for GBS services and requests 
world-wide. It would also serve as a primary JCS/National Command Authority data 


injection site. Current proposals indicate that this site may be managed by either DISA 


or USSPACECOM. 


NCTAMS 


MILSATCOM 


) | uplink / 
downlink 


DISN 
GBS request inputs, 


(IP routed data) system control and 
-“"| info management 


multiplexer 
other datastreams é ae 


Figure 5. NCTAMS as a GBS Theater Broadcast Management Center. 





D. CONCLUSIONS 


High data-rate direct broadcast services, recently perfected by civilian industry, 
represent a unique and timely opportunity for the US military to vastly improve its data 


dissemination architecture without extended research and development of proprietary 
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systems. It is not a stretch to note that the US military's operational requirements for 
high throughput broadcast services have been outpaced by the commercially-led DBS 
technology explosion. Yet, preliminary integration of GBS signal processors and 
stabilized antennas onto mobile platforms (e.g., ships) has been accomplished. 
Fourteen US warships are currently outfitted with commercial DBS systems, and GBS 
systems have been installed on several tactical platforms, including aircraft [Ref. 14]. 
Theater-level GBS systems are operational in Europe (in support of NATO Forces in 
the former Yugoslavia), and in the continental US for testing and concept evaluation. 

The GBS space segment architecture has, for the near future, been defined and 
set in motion. However, the current state of GBS information management, including 
data injection, requests for service and data format standardization, is seriously lagging 
behind its technical capabilities. CINC-controlled broadcasts, theater-direct data 
injection, and the effective integration of GBS with the DISN should compose the 
central focus of near-term GBS system development. 

Use of the NCTAMS as a theater focal point for GBS broadcast coordination 
allows a relatively simple migration of the legacy Fleet Broadcast subsystem to a new, 
robust, high-speed data link. Weather, intelligence and GENSER message traffic, 
currently transmitted at 75bps can now be integrated onto a GBS (23Mbps) datastream 
for broadcast to the fleet and other tactical users. The details of this proposed 
integration and how it can extend a DMS broadcast to tactical mobile units is the focus 


_ of the next chapter. 
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IV. DMS BROADCAST OVER GBS 


A. INTRODUCTION 





‘Current Navy proposals omit any near-term DMS broadcast capability. 
Instead, Navy tactical DMS plans call for the conversion of X.400 messages to 
the legacy AUTODIN formats via a Multi-Function Interpreter (MFI). The MFI will 
“translate” messages back and forth between X.400 and AUTODIN formats. 
Converted messages are then transmitted over the MILSATCOM 
duplex/broadcast systems to tactical nes This is a short term solution. With 
AUTODIN replacement mandated by 2000 [Ref. 2], a more flexible, integrated 
tactical DMS solution needs to be articulated. Furthermore, a DMS broadcast 
capability needs to be developed to replace the existing Fleet Broadcast system. 

As outlined in Chapter I, DoD development of a new protocol (CMTP) will 
allow data transmission from an originating MTA to a recipient MTA without the 
need for application-layer connectivity and acknowledgment of message 


delivery. This alteration, however, is directed at the higher (application) layer 


link. The NIPRNET (on which DMS messages are carried) cannot be extended 
over a broadcast network, chiefly because TCP can only operate over a 
interactive (duplex) link. 

In response to this limitation, it is expected that after development of 


| 
| 
| 
| 
and does not address the general restrictions of TCP/IP over a connectionless 
CMTP, broadcast DMS will incorporate an unreliable, broadcast-capable 
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transport protocol known as UDP (User Datagram Protocol) [Ref. 15]. This 
simplex-capable protocol enables the transport of datagrams without sequencing 
information, error correction or the capability for retransmission of lost packets. It 
allows a sending node to transmit datagrams without responses 
facriowiedoments) from the receiving node. However, use of UDP is traded off 
against possible datagram non-delivery, error correction and/or duplication. UDP 
is an unreliable method for transporting operational message traffic. 

The DMS Tactical Working Group reports that preliminary broadcast DMS 
testing can be expected after 1999 [Ref. 16]. Meanwhile, tactical units will 
receive messages of greater size (due to X.400/AUTODIN conversion overhead, 
MISSI and multimedia enclosures) over current MILSATCOM systems at 
75-9600 bps. 

This chapter presents a viable solution for DMS extension to the tactical 
environment and a conceptual outline for a robust broadcast network to replace 
the current Fleet Broadcast system. The concept integrates relatively new IP 
routing schemes with the GBS broadcast system presented in the previous 
chapter. The application of GBS as a "next generation" Fleet Broadcast offers 
an expansive leap in tactical broadcast communication capability. The proposed 
communications architecture is a high data-rate broadcast system, capable of 
carrying DMS traffic to tactical units. Some assumptions are made within the 


scope of the concept as presented; they are: 


*NCTAMS are outfitted with GBS subsystems and routers capable of 
forwarding DMS data packets to them 
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- The DISN is fully operational and ties together all terrestrial DoD 
communication nodes 


- The four NCTAMS are linked via the DISN, as outlined in Chapter | 


- GBS is implemented with (as required) world-wide coverage. 


B. ENABLING TECHNOLOGIES 


The most critical aspect of this tactical DMS broadcast concept is the 
effective routing of messages to mobile units which are not continuously 
connected to the same network (DISN) interface. IP version 6 (IPv6) and mobile 
IP, both recently developed commercial protocol standards, address this 
requirement. Their use can effect a general, scaleable and easily implemented 


solution to the problem of broadcasting DMS messages to mobile, tactical units. 


1. IPv6 and Anycast Addressing 


IPv6, formalized by an Internet Engineering Steering Group in November 
1994, was developed as an evolutionary improvement over the current Internet 
Protocol (IP version 4) [Ref. 17]. It can be installed as a software upgrade in 
Internet devices (routers, switches, gateways, bridges, etc.) and can coexist with 
systems using the current IPv4. Furthermore, IPv6 is designed to run well on 
high performance networks (e.g., ATM switched networks) while at the same 
time is still efficient for low bandwidth networks (e.g., MILSATCOM). Key 


upgrades from IPv4 to IPv6 include [Ref. 17]: 


- expanded routing and addressing capabilities. IPv6 increases the IP 
address size from 32 bits to 128 bits, which supports more levels of 
addressing hierarchy, a much greater number of addressable nodes, and — 
simpler auto-configuration of addresses. 
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- header format simplification. Some IPv4 header fields have been 
dropped or made optional, to reduce the processing cost of packet 
handling and to keep the bandwidth cost of the IPv6 header as low as 
possible despite the increased size of the addresses. Even though IPv6 
addresses are four times longer than the IPv4 addresses, the |Pv6 header 
is only twice the size of the IPv4 header. 





- improved support for options. Changes in the way IP header options 
are encoded allows for more efficient forwarding, less stringent limits on 
the length of options, and greater flexibility for introducing new options in 
the future. 

- quality-of-service capabilities. A new capability is added to enable the 
labeling of packets belonging to particular traffic "flows" for which the 
originator requests special handling, such as acknowledgments or 
"real-time" service. 

- authentication and privacy capabilities. This includes the definition of 
extensions which provide support for authentication, data integrity, and 
confidentiality. : 


- multiple addressing schemes. Besides the standard unicast address, 
IPv6 incorporates multicast addressing and anycast addressing. 


IPv6 represents a cost-effective, non-developmental, backward- 
compatible upgrade to the current IP protocol. It should be adopted for DISN 
implementation, even if just for its 128 bit address size and the ability to multicast 
data packets. Of primary importance to this thesis, however, is the development 
of a new addressing scheme within IPv6 known as the anycast address. 

An anycast address is an IP address assigned to more than one network 
interface (e.g., router). Its primary property is that a datagram sent to an anycast 
IP address is routed to the "nearest" interface advertising that address. 
"Nearness" is based on the routing protocol's measure of distance, vice physical 


distance, and takes traffic load and throughput speed into consideration 
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[Ref. 17]. In essence, anycast addresses are created when a node's unicast 
address (unique IP) is assigned to more than one network interface. 

This new addressing scheme allows several network interfaces to receive 
and accept datagrams for a single node. In this manner a node can move from 
one network interface to another, share anycast addresses between itself, its 
new host and any other interface, and be assured that datagrams will be routed 
to it regardless of which interface actually receives them. Furthermore, a node 
can use its "home network" IP address as an anycast IP address, therefore 
negating the need to update or change its IP addresses every time it moves to a 


new network interface. A graphical representation of the anycast IP address 


concept is depicted in Figure 6. 


mobile node 
4 e we. 
“tN 


ke 
router A fi [| router B 


“ 


network 


both routers (network interfaces) advertise the mobile node's IP address. 
The mobile node can receive datagrams from either router. Which router receives the 
datagrams depends on the "nearness" of the sender to each interface. 





Figure 6. Anycast IP Address Scheme 


In order to effect a seamless transfer of datagrams from all anycast 


interfaces to the intended recipient node, another routing scheme must be 
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incorporated. Specifically, the details of how datagrams are passed from an 
accepting anycast interface to a mobile recipient node, not physically connected 


to that interface, are outlined below. 


2. Mobile IP 


| Documented in February of 1996 by the Mobile IP Working Group of the 
Internet enainesnne Task Force, mobile !P allows automatic routing of 
datagrams to mobile nodes regardless of their geographic location or use of 
different network interfaces [Ref. 17]. The concepts behind mobile IP are not 
tied to the use of either IPv4 or IPv6; they can be implemented on a network 
which uses either (or both) protocols. 

Current IP routing schemes assign a unique IP address to a network 
node. This IP distinguishes it from all other nodes on that network. If the node 
becomes mobile and cannot directly connect to its home network, it must change 
its IP address in order to receive datagrams while connected to the new network. 
This method can often cause loss of connectivity until the node's new IP address 
has been registered throughout the network's routing tables. Mobile IP offers a 
mechanism through which mobile nodes can connect to any network interface 
and still receive their data. 

' A mobile node is always associated with the IP address of its home 
interface, known as a home agent, even when physically away from its home. 
When away from home, the node is also associated with whatever interface it 


uses to reconnect to the network. The "away" interface, known as a foreign 
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agent, is registered with the home agent whenever the mobile node chesien 
network interfaces. The home agent then reroutes all datagrams intended for 
the mobile node to that unit's foreign agent for delivery. The home agent "wraps" 
the datagrams in another IP datagram whose address header contains the IP 
address of the foreign agent. This process is known as "tunneling". The foreign 
agent "unwraps" the tunneled datagram, reads the IP ilies of the contained 
datagram and delivers it to the intended mobile node. In this manner the home 
agent maintains a virtual connection with the mobile node through the foreign 
agent which maintains a physical connection. Datagrams sent by the mobile 
node are delivered to their intended recipient using standard IP routing; they are 
not routed through a home agent. Figure 7 depicts a simple overview of the 


mobile IP concept. 


2. the home agent re-routes the datagrams to the mobile node's 
foreign agent via a mobile IP "tunnel" 


3. datagrams are delivered 
to the mobile node by the foreign agent 


foreign 


ne node 
4. datagrams from the mobile node to a network host 
are delivered via standard IP routing 


I . the originating host does not know (nor should it care) that the mobile 
node is not at its home network. It sends all datagrams to the 
home IP address of the mobile node. 





Figure 7. Mobile IP Routing Concept. After Ref [17]. 


41 





C. GETTING A DMS MESSAGE TO A TACTICAL UNIT 


In order to organize the DMS broadcast over GBS concept in a manner 
related to the operational aspects of tactical units, it is presented based on the 
following scenario: Two ships, homeported at Naval Station Mayport, Florida are 
preparing to get underway. USS SPRUANCE (DD-963) is scheduled for a six 
month Mediterranean deployment. USS GETTYSBURG (CG-64) is preparing for 
a two week exercise off the eastern US coast. SPRUANCE has Commander 
Destroyer Squadron 2 (COMDESRON 2) embarked. At the same time two other 
naval vessels, USS HOUSTON (SSN-713) and USNS ALTAIR (T-AKR 291), a 
civilian-manned rapid response cargo ship, are currently on station in the Pacific. 
The scenario will incorporate the flow of DMS messages as they are routed over 
the DISN (NIPRNET) and GBS to finally arrive at the correct unit. Details on the 


accomplishment of specific messaging processes are delineated as they occur. 


1. Unit Pierside 


In this case the tactical unit is no more than a building afloat on the water. 
DISN connectivity, and therefore DMS connectivity, are obtained via the port's 
Naval Communications Station (NAVCOMSTA) acting as home agent. Tactical 
units access the NAVCOMSTA's DISN routers via a dedicated, dial-up access 


phone line.’ Eventual rewiring of homeports with coaxial cable, fiber optic or 


RR A A A pr A 2 pe 


"A very viable alternative is the continued reception of DMS traffic over the 
GBS system even while moored inport. This is, however, a doctrinal vice 
technical question and is not examined in this thesis. 
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even wireless (line-of-sight) extensions to pierside units would certainly be a 
welcomed improvement, but they do not alter the basic premise of tactical unit 
connectivity: tactical units are mobile and therefore must be able to disconnect 


from the pierside connections and not lose communication connectivity. 


2. Unit Underway 


Once underway, the direct DISN (and therefore DMS) interface for each 
tactical unit will be a NCTAMS. Twenty-four hours prior? to getting underway 
from homeport, communication personnel aboard the tactical units inform their 
respective homeport's NAVCOMSTA of their expected departure. This process is 
known as a communication guard shift or "com-shift". The IP routing tables 
within the NAVCOMSTA's DISN router and DMS MTA are updated to indicate 
that these subscribers are out of homeport. Each tactical unit's com-shift 
message really establishes an anycast address scheme between its 
NAVCOMSTA, the NCTAMS under whose contro! it falls, and itself. The 
NAVCOMSTA's routers are also updated to automatically reroute all message 
traffic intended for the underway unit back over the DISN to a NCTAMS using a 
mobile IP tunnel (home agent to foreign agent routing). 

Concurrently, tactical units also report changes in their operational status 
to the NCTAMS nearest their homeport (or port of departure). The NCTAMS' 


DISN router is reconfigured by operators as a foreign agent, based on the 

















* Based on current USN policies. Efficient use of network technologies can 
considerably reduce the time lag involved in shifting communications guard. 
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tactical unit's requests, which accepts receipt of DMS messages addressed to 
the tactical unit. The NCTAMS MTA, which maintains a duplex DISN 
connectivity, accepts, error-corrects and reassembles all DMS datagrams. The 
in-sequence, error-free DMS message datagrams are then routed to the GBS 
subsystem (ATM multiplexer) for broadcast queuing. The NCTAMS MTA also 
returns a modified acknowledgment of receipt to the originator. The modified 
acknowledgment should, at the minimum, state that the message has been 
received by the NCTAMS for GBS queuing and indicate receipt date and time. 


This informs the message originator not to expect immediate receipt or read 


acknowledgments from the intended recipient, as DMS standards mandate. The 


NCTAMS' messaging system can also relay acknowledgment of GBS message 
transmission (or when it will be transmitted) back to the originator. In essence, 
the NCTAMS acts as the connectivity point for broadcast messages addressed 
to all underway tactical units within its area of responsibility.* Figure 8 is a simple 
overview of the proposed routing scheme and how it incorporates the anycast 
and mobile IP concepts. 

For the proposed scenario, the "com-shift" message initiated by 
GETTYSBURG prior to getting underway informs NAVCOMSTA Mayport (home 
agent) to route all traffic to NCTAMS LANT (foreign agent). NCTAMS LANT, 


also informed of GE 'TYSBURG's underway status, accepts responsibility as 











* This could occur in much the same manner that it does now. Itis expected 
that extension of duplex DMS connectivity to tactical units will also occur via the 
current NCTAMS sites. 
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GETTYSBURG's foreign agent, returns DMS alien acknowledgments and 
reroutes message datastreams to the GBS subsystem for transmission. DMS 
traffic sent to GETTYSBURG's IP address (now shared amongst itself. 
NAVCOMSTA Mayport and NCTAMS LANT as an anycast address) will either 
be routed to NAVCOMSTA Mayport, who then tunnels them to NCTAMS LANT, 


or directly to NCTAMS LANT for broadcast. 


NCTAMS ee 


NAVCOMSTA 


@ tactical unit (at sea) 


mobile IP tunnel (over the DISN) 


NAVCOMSTA and NCTAMS share anycast IP with tactical unit. 
Datagrams addressed to unit can be accepted by either. If NAVCOMSTA 
receives them, it will tunnel them to NCTAMS for broadcast. 





Figure 8. Proposed Mobile IP/Anycast Routing Scheme. 


The use of anycast addresses ensures that all DMS traffic is received either 
at the NAVCOMSTA or the NCTAMS, depending on which is the nearest 
interface. Remember that the current IPv4 ties a node to the network from which 
it received its IP address. This means that the tactical unit (while in homeport) is 
seen as a node of the NAVCOMSTA's DISN subnet, and that subnet will be 
advertised as the physical location of the unit, even when it is not there. While 
underway, the anycast address scheme insures that mobile tactical users can 


maintain at least one network interface at all times, therefore maintaining 
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network connectivity. It also overcomes the need to update and/or sida a 
unit's IP address just because it changed its network interface (e.g., moves from 
one NCTAMS to another). While inport, and directly connected to the DISN, the 
sharing of anycast addresses is discontinued (by a com-shift message) and the 
tactical unit regains sole ownership of its unique IP address. 

A simple routing scheme for mobile units can be developed using just the 
mobile IP construct previously outlined. However, this would force all message 
datagrams to be initially routed to the unit's home agent (homeport 
NAVCOMSTA). The home agent would then retransmit these datagrams to 
wherever the mobile unit was physically located at the time (foreign agent). The 
anycast address scheme minimizes this network routing overhead by allowing 
several interfaces to advertise the IP address of a mobile unit. For instance, 
message datagrams from an originator located in Japan wishing to send a 
message to HOUSTON should not (normally) have to travel all the way to the 
HOUSTON's homeport NAVCOMSTA (in San Diego, CA), to then be rerouted to 
NCTAMS WESTPAC for broadcast. Ideally in this case, the nearest interface 
will be NOCTAMS WESTPAC, who maintains direct GBS connectivity with 
HOUSTON. 

In another example, SPRUANCE enters the Mediterranean and shifts 
communication guard fom NCTAMS LANT to NCTAMS MED. A com-shift 
message informs NCTAMS LANT to drop SPRUANCE's IP address from their 


routers, and NCTAMS MED to add it to theirs. Now ali DMS datagrams intended 
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for SPRUANCE are routed via the DISN to either NAVCOMSTA Mayport (who 
then tunnels them to NCTAMS MED) or directly to NCTAMS MED for GBS 
broadcast. Anycast addressing allows NAVCOMSTA Mayport to maintain a 
continuous network interface for SPRUANCE messages, even during NCTAMS 


transitioning periods. 


3, DMS Broadcast to an Embarked Unit 


Message traffic addressed to an embarked unit (e.g., COMDESRON 2) is 
routed in a similar manner. The embarked unit is responsible for initializing an 
anycast address in conjunction with their host unit. There are two methods by 


which this can be accomplished: 


- The embarked unit notifies its homeport NAVCOMSTA of which host unit 
it will be underway in. The embarked unit then shares the anycast 
address of its host unit, and does not have to add its own IP to the 
NCTAMS routers. This helps in the reduction of routing table size and 
update frequency. However, the IP address of the embarked unit must be 
integrated into the routing tables of the host platform, who segregates and 
internally routes messages to the embarked unit. Embarked units 
assigned to ships with a single MTA ships would benefit from this method. 


- The embarked unit acts like a stand alone entity and sends messages to 
update both their NAVCOMSTA and NCTAMS routers. A key advantage 
is the ability to individually receive traffic if the host unit can support 

multiple MTAs, each linked to a GBS receiver. This configuration is most 


appropriate for larger platforms such as command ships, aircraft carriers 
and amphibious vessels. 


In either case, all subsequent message routing instructions are delineated 
by com-shift messages. A com-shift message from a tactical unit to a NCTAMS 
can include the IP addresses (and email addresses) of all embarked units (e.g., 


helicopter squadrons, meteorological detachments, embarked staffs and marine 
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detachments). This concept allows embarked units to maintain the same IP 
address regardless of whether they're in port or at sea. 

In the scenario, DMS messages addressed to COMDESRON 2 are routed 
to either NAVCOMSTA Norfolk (who then tunnels them to NCTAMS MED) or 
directly to NCTAMS MED, who accepts receipt and queues the messages for 
GBS broadcast to SPRUANCE. SPRUANCE's MTA then sorts and routes the 


messages to COMDESRON 2's UA. 


4. Shipboard Message Flow 


The GBS broadcast, transmitted at 1.544 Mbps or 23 Mbps depending on 
CINC requirements and the tactical unit's geographic position, is captured by one 
or more small shipboard receive antennas’. The ATM datastream, specifically 
the channel! carrying DMS traffic, is demultiplexed and decrypted. The GBS 
terminal accepts only those data cells addressed to the unit, discarding the rest. 
In the case of DMS, the error-corrected and in-sequence message datastream is 
routed to the ship's MTA (most likely the current NAVMACS Il) for X.400 address 
profiling, and routing within the ship's network to the intended recipient's UA. 
The first datagrams received by the MTA initiate a CMTP-based message 
transfer session. Use of the CMTP protocol allows the recipient (shipboard) 
MTA to accept the datagrams without a P1 level connection between itself and 


the originating (NCTAMS') MTA. The NAVMACS II can also be configured to 


*Most certainly, more than one antenna, linked by a shipboard LAN, is 
necessary to improve signal reception, system survivability, reduce topside 
placement constraints and allow for multiple MTA configurations. 
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transmit message receipt/read confirmations over a duplex link, if required. The 
ability of NAVMACS II to act as a DMS MTA was proven during tests aboard 
USS KITTY HAWK (CV 63) in conjunction with the Joint Warrior Interoperability 
Demonstration 1995 (JWID 95) [Ref. 19]. Figure 9 depicts the proposed 


shipboard data and DMS message flow. 


Antenna LAN 
GBS sis 
terminal 
video efc.. 
other data 


} DMS data 


video 
terminal 
NAVMACS 


Shipboard LA 





Figure 9. Shipboard Data/Message Flow. 


D. DOCTRINAL ASPECTS: SMART PUSH, USER PULL 


The proposed system allows for a more robust management of tactical 
broadcast messaging. For instance, along with the shift in communication guard 
and DMS message acknowledgment, the NAVCOMSTAs and NCTAMS are 
tasked by each unit of any special priorities, long-term storage needs and GBS 


broadcast requirements. These instructions act as the "smart warrior pull" aspect 
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of this tactical DMS concept.*® Proper Soplication of broadcast, computer, email 
and network technologies can greatly enhance the tactical user's ability to 
specifically tailor their data communications service needs, regardless of how 
they connect to the network. Some examples of this concept are outlined below. 


References to the given operational scenario are delineated in italics. 


1. Specific Times to Transmit Messages 


DMS guidelines call for at least ten days of message storage capacity. 
This needs to be higher, especially for those units with irregular communications 
needs. 

HOUSTON, due to operational necessity, has irregular communication 
black-outs. She has instructed NCTAMS WESTPAC to hold all IMMEDIATE and 
below DMS traffic for bulk GBS transmission at preset times or after she has 
contacted them. Notifications of FLASH traffic (and higher) are made using 
current systems (e.g., HF, VLF). The high priority messages are transmitted 
continuously over GBS until acknowledgment of receipt (verbal or message or 
both) is received at the NCTAMS. 

ALTAIR, whose operational message traffic requirements are much lower 
than most other units, has all DMS traffic broadcast to her four times daily. 


GETTYSBURG, SPRUANCE and COMDESRON 2 have all their DMS traffic 





° User-defined messaging parameters are not a new concept. However, 
continued application of Internet-based technologies, such as WWW and email 
in the tactical environment, offers several new possibilites on how those 
parameters are defined, exchanged and updated [Ref. 8]. 
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queued and transmitted over GBS upon receipt at NCTAMS LANT and NCTAMS 


MED. 


2. Receipt Confirmations 


Tactical users will dictate how receipt of messages will be accomplished 
(e.g., in bulk). This can be done over duplex links, with the tactical unit 
transmitting a database of received message date-time groups twice daily. 
Messages not confirmed as received can be automatically retransmitted by the 
GBS system. Confirmation of message receipt and read by the tactical recipient 
is transmitted over duplex DMS links back to the originator, if required. 

COMDESRON 2, expecting a heavy DMS traffic load during operations in 
the Adnatic Sea, instructs NCTAMS MED that only IMMEDIATE and above 
precedence messages will be confirmed as received. Receipts will be 
accomplished in bulk format, three times daily. Originators of all other DMS 
traffic will receive a preformatted message stating that "your message addressed 
to COMDESRON 2 has been transmitted over GBS. Due to operational 
constraints no direct acknowledgment of receipt by COMDESRON 2 is 


expected". 


3. Routing Instructions for High Priority Messages 


This concept allows the tactical user to tailor the transmission of 
high-priority messages. For example, all FLASH traffic can be sent over GBS 


and/or duplex systems continuously until receipt is acknowledged. 
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GETTYSBURG, expecting notification of possible surge-deployment to the 
Caribbean, has instructed NCTAMS LANT to route all FLASH traffic over both 


GBS and duplex systems to improve probability and speed of reception. 


4. Storage of Messages With Certain Header Data 


NAVCOMSTA and NCTAMS local message stores can hold specified 
message types/addresses until the tactical unit can "log in" to the DISN and 
download them. This concept closely follows the Navy's current "gateguard" 
communication architecture. 

GETTYSBURG instructs NCTAMS LANT to hold all ROUTINE DMS traffic 


during their 2 day transit from Mayport, FL to Norfolk, VA. 


E. ADVANTAGES 


The proposed DMS broadcast over GBS (DMS/GBS) concept offers 


several advantages, each presented below. 


1. Simplicity 

This concept outlines a simple yet scaleable broadcast capability which 
can be integrated into other tactical DMS implementation efforts. It resolves the 
problem of TCP connectivity over a connectionless link, overcomes the 
mobile-user restrictions of the current IP protocol, while also addressing the 
connection needs of the X.400 application protocols. The only new development 
required is a completion of the CMTP to replace the current P1 protocol. 


Moreover, it outlines a new, compatible method of TCP/IP-based messaging 
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over the existing DISN infrastructure that accommodates the unique limitations 


and needs of the mobile user. 


2. Performance 


DMS/GBS offers an order of magnitude jump in broadcast technology 
over the existing Fleet Broadcast system, one that also integrates mandated 
DMS interoperability. Whether the data is transmitted at 1.544Mbps or 23Mbps, 
the jump in throughput performance makes GBS a logical choice for large scale, 
tactical, data dissemination. Appendix C depicts a comparison of data 


throughput performance using various military communications system, 


highlighting the gain in message delivery speed offered by GBS. 


3. Security 


There is no reduction of MISSI security standards. Datagrams (DMS 
messages) are not decrypted by the intermediate interfaces, only repackaged 
and rerouted. Transmission over the GBS, with bulk encryption of the 


datastream, adds another layer of security to DMS message dissemination. 


4, Relief of MILSATCOM Burdens 


DMS/GBS implementation offers a reduction of message traffic 
congestion over the current duplex MILSATCOM systems. With the vast 
majority of operational traffic to tactical units handled by the DMS/GBS system, 
duplex systems can better accommodate high-priority messaging, GBS user 


service requests and shore-bound DMS traffic from the tactical units. 
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5. Near and Long-Term Utility 


The proposed system offers a near-term tactical DMS utility while more 
robust duplex links are developed. It also identifies the frame-work for a 
long-term DMS broadcast link. Furthermore, the routing and transport concepts 
applied in this anes (mobile IP, anycast, IPv6) can be adapted to any IP routed 


data network in order to achieve a mobile user connectivity. 


r, LIMITATIONS 


There are two primary limitations imposed by this concept. However, the 
limitations apply to all other current tactical DMS proposals as well. Neither 
limitation affects the scaleability, connectivity or capability of service, only the 


elements of service available to the tactical DMS user. 


1. Receipt Acknowledgments 


Under the DMS/GBS concept, immediate acknowledgment of message 
receipt or read by the intended recipient is not available. Only receipt/queuing 
acknowledgments by the responsible NCTAMS are immediately returned to the 
originator. However, delayed acknowledgments can be initiated by the tactical 


unit via a duplex DMS link. 


2. X.500 


The ability to immediately search the distributed X.500 directory of X.400 


addresses and user data cannot be accomplished over the proposed system. 


04 








However, tactical units can download the current X.500 database (or subsets of 
it) prior to getting underway. Once at sea, updates to the database can be 
requested via duplex links and transmitted to the tactical unit via the GBS 


broadcast. 


G. CONCEPT SUMMARY 


In summary, the challenge of broadcast DMS extension to the mobile 
tactical unit is resolved using new routing techniques and high throughput 
broadcast links. When underway, units maintain anycast addresses with their 
homeport NAVCOMSTAs and with the individual NCTAMS accepting traffic for 
them. DMS messages addressed to a tactical unit are sent to the nearest 
interface holding that unit's anycast address. If the nearest interface is the ship's 
homeport NAVCOMSTA, and the ship is out of homeport, then the message 
datagrams are encapsulated and rerouted by the NAVCOMSTA to the NCTAMS. 
If the nearest interface is the NCTAMS itself, then no further routing is required; 
receipt of the message is acknowledged and it is queued for GBS transmission. 
The transport and application layer protocol problems, outlined in Chapter | and 
in the introduction of this Chapter, are resolved by having the NCTAMS' routers 
ne all error checking, retransmit requests and datagram sequencing prior to 
queuing message datagrams for ATM broadcast over GBS. The application of 
CMTP protocols at the NCTAMS and shipboard MTAs allow DMS datagrams to 


be successfully transmitted over a simplex link. The result is an in-Sequence and 
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error-free DMS datastream transmitted over a high-speed simplex link to the 
tactical user. ° 

The proposed system relies on the integration of IPv6, CMTP and the use 
of mobile IP constructs within the DISN environment. There are also some 
hardware, infrastructure and management issues which must be concluded 
before this system can be implemented. These issues, and proposals for their 


resolution, are the focus of the following chapter. 





° The concept of using an intermediary router which maintains a duplex link 
with one node and a simplex link with another was originally developed for use in 
network security. This concept allows unclassified nodes to pass traffic to 
classified nodes, but stops any transfer of data from a secure node to a 
unclassified node. The intermediary router receives datagrams from a 
unclassified node via a duplex link, generates acknowledgments to the sender, 
repackages the datagrams with error correction and sends them out a separate 
simplex link to the classified recipient. In this manner the unclassified node has 
no direct access to the classified network but can still pass data to it; while the 
classified nodes cannot transmit to the unclassified network. 
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V. RECOMMENDATIONS AND CONCLUSIONS 


The previous chapter outlines a concept of operations for a high data-rate, 
DMS-capable broadcast service. The actual implementation of this concept 
relies heavily on the application of recent technologies and the resolution of 
specific issues within the developing DISN framework. An information 
distribution system, such as the proposed DMS/GBS system, is only as robust 
and effective as the underlying network which supports it (DISN). Improvements, 
therefore, in the effectiveness of the common network benefit all subsystems 
which rely on it. The proper design of a supporting network should be the first 
priority in the restructuring of the military's information distribution system. 
Furthermore, this design must include data distribution standards to which all 
network clients must conform. It is no longer fiscally or technologically effective 
or efficient to design and implement independent information subsystems only to 
later force their interoperability over a network. This "network-centric" approach 
to information distribution systems provides the greatest freedom for subsystem 
design while simplifying any future network and subsystem expansion [Ref. 8]. 
A. NEAR-TERM RECOMMENDATIONS 

The following recommendations should be viewed as a list of technologies 
which can be applied to expand the usability, scaleability and performance of the 
overall DISN. These specific recommendations can be implemented in the 


near-term to improve the DISN without significant DoD development or network 
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restructuring. The generation of a comprehensive set of requirements for 


implementation of the proposed DMS/GBS system is left for a follow-on effort. 


1. Infrastructure: World-Wide GBS Coverage 

There is currently no better alternative for expanding the information 
broadcast capabilities of military communications than with the GBS. The 
military's requirement to project a presence anywhere in the world mandates that 
its supporting information infrastructure be based on global connectivity. The 
modification and launch of all three GBS-capable UFO satellites (#8, #9, #10) 
should be considered a minimum first step in establishing a very critical aspect of 
this capability. A initial assessment of GBS as a dissemination system for DMS 
can be made using the current testbed GBS (CONUS-based) system operated 


by the NRO. 


2. Accelerated Development / Fielding of CMTP 

The Connectionless Message Transfer Protocol promises to alleviate X.400 
of its restriction to duplex-only links. Until this protocol is fully developed, the US 
Navy Fleet Broadcast subsystem (albeit, all broadcast systems) will remain 
unable to transmit X.400 messages without extensive format conversion and a 
severe reduction of the tactical user's DMS elements of service. Delays in the 
development and application of CMTP translate to a continued degradation in 


DMS connectivity to the tactical environment. 
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3. Application of IPv6 on the DISN 

The proposed DMS/GBS system relies heavily on IPv6's anycast address 
scheme. However, IPv6 should be applied to the DISN architecture not because 
it is required by any one system or proposed concept, but because it supplies a 
vastly improved routing and addressing structure to a network. IPv6 therefore 
allows for extended network growth and the application of more robust 
information management schemes. If for no other reason IPv6 should be 
implemented on the DISN for its expanded address space and multicast 


capabilities. 


4. Application of the Mobile IP Concept 

In much the same manner as IPv6, Mobile IP constitutes a commercially 
developed, backward-compatible concept which expands network capability 
without affecting the overall network structure. As military data communications 
move toward the DISN vision, Mobile IP offers a near-term, relatively simple, yet 
effective method of integrating the highly mobile subscriber without development 
of proprietary protocols or subnets. Implementation and testing of this concept 
on the Navy's NCP II can be made with little or no disruption to operational 


message traffic. 


5. NCTAMS as DMS and GBS Theater Management Centers 
As theater-wide routing and switching centers, NCTAMS already provide a 
key link between the Navy's information networks and the warfighter. If DMS 
and GBS are extended as planned to the warfighter arena, they should be 
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placed under the operational control of the theater CINCs. Uniting these 
subsystems and their theater-level management operations under one NCTAMS 
roof means not having to add new networking layers to a CINC's communication 


infrastructure. 


B. LONG-TERM RECOMMENDATIONS 

It can be effectively argued that the most important aspects in the 
development and implementation of any information system are a clear strategic 
vision of that system's intended application and the realization that continual 
improvement as a function of the architecture must be incorporated into the initial 
design. However, these design issues are probably the most difficult to detail as 
well. This is especially true in the case of the DISN, GBS and DMS, where the 
system has already been designed and implementation has begun. Therefore 
the following long-term recommendations are of a more technological rather than 
design nature. While these recommendations are founded in the improvement of 
the current DMS and GBS, they are not entirely based on what is required to 
implement the proposed DMS/GBS system. They should be seen as general 
comments and opinions on what may assist in providing a robust, long-term 


military data communication infrastructure. 


- Continued expansion of the GBS earth coverage. The current three 
satellite constellation constitutes the minimum required; it does not 
provide for system redundancy or polar coverage. 


- Integration of the (still under development) Low Earth Orbit 
Satellites (LEOS). This commercially developed satellite-based system | 
is aimed at world-wide voice and data connectivity. These systems 
represent a (promised) large-scale upgrade in world-wide networking and 
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information distribution. DoD should prepare integration plans and system 
implementation analysis before, not after, these systems are placed in 
service. Anticipation of this capability may reduce the initial lag in 
effective information management integration which has challenged the 
GBS. | 7 


- Maintain the VLF, HF and UHF systems as back-ups. They are paid 
for, in-place and operational. Why limit the channels of dissemination? HF 
systems remain the only non-satellite, long-haul communication link, and 
VLF stands as the only means to communicate with submerged 
submarines. As such, the VLF and HF media act as needed 
complements, not competition, to satellite-based systems and should be 
integrated into the DISN infrastructure [Ref. 8]. 
- Maintain (expand on) an X.400 to SMTP connectivity. Simple 
Mail Transfer Protocol (SMTP) is the standard for email communications 
within the commercial Internet. DMS users will require connectivity to 
email systems outside the DoD, and it appears that there will be very little 
X.400 market penetration into the commercial world. Furthermore, as 
development of SMTP and associated email protocols continues in the 
commercial arena, DoD may well have to reconsider its adoption of X.400. 
C. AREAS REQUIRING FURTHER STUDY 
This thesis presented a general concept of operations for a DMS/GBS 
broadcast system. The next logical step in the development of this concept is 
the accurate modeling and simulation and prototyping of the proposed system. 
Several individual technologies ( e.g., IPv6, Mobile IP, GBS, CMTP) were 
incorporated in order to arrive at the final system concept. Obviously, continued 
analysis of each individual technology and its application to the military 
communications environment is required. In the case of the proposed DMS/GBS 
concept, the simulation and integration of the several individual parts should be 


the modeler's first priority. Accurate system simulation, if even possible, may 


well prove a secondary fallout of what is learned by the efforts undertaken to 
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integrate these individual technologies. Specifically, any modeling/simulation 


efforts based on the proposed concept should: 


- Test the NCP's ability to act as "intermediary" TCP/IP relay system 
which ties together duplex and simplex links. What hardware, software 
and management are required to enact this integration? What time delay 
and data overhead is added? 


- Test the general scaleability of the proposed anycast IP concept, 
specifically at the NCTAMS router. How many users can effectively be 
supported by one NCTAMS router? Based on delivery times, scaleability 
and ease of use, is the concept better than re-assignment of IP addresses 
to mobile units? 


- Evaluate the usability of Mobile IP in a dynamic tactical 
environment. What constraints or limitations are there in the scaleability 
of this concept to an entire fleet or Navy? What data delivery delays are 
introduced? What hardware/software modifications are required by the 
home and foreign agents? What are the security considerations? 


- Test the capabilities and limitations of CMTP (when available). Does 
it really allow a simplex MTA connectivity? Can it coexist with the 
standard P1 protocol? What quality of service limitations are imposed? 
How can the capability be best implemented and managed? 


- Examine what hardware/software modifications are required to 
integrate the GBS datastream and the shipboard MTA (NAVMACS?). 
Are (low data-rate) back channels required to effect a reliable link? What 
are the effects and consequences of unexpected link disruption caused py 
atmospheric disturbances on message delivery? 


- Examine addressing issues. Operational messages are traditionally 
sent to a unit, not an individual. What doctrinal changes are required (if 
any) to support, manage and exploit (limit?) the addressing capabilities of 
DMS? 


- Outline network management. Develop a comprehensive (end-to-end) 
plan for automated network management, to include fault location, 
maintenance and restoration. Model system performance under stress 
(jamming, node destruction, peak traffic loading, and environmental 
factors). 
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While not the focus of this thesis, it should be noted that there remain 
several alternatives and unanswered issues in the seamless extension of duplex 
tactical DMS. These varied alternatives, which encompass both technological 
and information management aspects, require further exploration, analysis and 


testing. The issues include such topics as: 
- Modeling and testing of the proposed MFI (Multi-Function 
Interpreter) concept. What overhead, errors and time delays are added 
to the system by its use? How does the reduction in DMS elements of 
service caused by the MFI effect the tactical user and/or the message 
originator? ais 
- Alternatives to the continued use of low-rate MILSATCOM systems 
for DMS tactical connectivity. What military or commercial 
communications systems are in development which can increase DMS 
connectivity and system availability at the tactical level? 
- DMS personal messaging. DMS extends messaging capabilities down 
to a personal, vice the traditional, unit level. How will this affect the overall 
operational DMS? What doctrinal and operational (security?) implications 
are involved? 
D. CONCLUSIONS 
DoD messaging is moving to the Defense Message System. Ultimately, 
DMS will be implemented in all DoD environments: tactical, strategic, fixed and 
mobile. However, while DMS efforts are aimed at providing multimedia 
messaging capabilities, the networks used to pass these messages are not 
being expanded to meet the new requirements. The Navy's Fleet Broadcast 
subsystem is particularly ill-equipped to handle DMS traffic. Broadcast systems 


are, however, an integral and, with GBS, a growing part of modern military 


communications, especially during covert or emission controlled (EMCON) 
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operations. The Navy's Fleet broadcast must iateaiebdeaa if it is to become a 
seamless extension of the DMS infrastructure into the tactical environment. 

At the same time the US military is developing a new satellite-based data 
dissemination system known as GBS. Early applications of GBS are aimed at 
theater-wide database updates and video brendan However, this system can 
also be used as a new high-throughput message dissemination service. The 
GBS in effect becomes a new Fleet Broadcast subsystem. In this manner, not 
only is the broadcast capability of DMS expanded, but the overall load on duplex 
MILSATCOM systems is reduced. 

This thesis attempted to present one possible method of integrating the 
DMS and GBS systems. This effort was undertaken in order to explore how the 
DMS messaging capability could be extended to the mobile, tactical user via a 


new, more robust broadcast subsystem. 
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APPENDIX A. OPEN SYSTEMS INTERCONNECTION (OSI) 
REFERENCE MODEL. AFTER REF [21]. 


OSI LAYER PRIMARY FUNCTIONS 


File transfers 
Electronic mail 
Databases 


application layer 


s X.400 


Syntax conversion 


presentation layer 
Data structure 


Applications / programs 


session layer ; 
y Session control 


Quality of network service 
End-to-end integrity 
Network service definition 


transport layer 


. TCP/ 
Network operations |p ** 


Switching and routing 
Network interfaces 


network layer 


Line integrity 
Error checking 
Flow control 


data link layer 


Timing and encoding 
Physical connectors 
Cables, Wires, Fiber 


physical layer 


“* Approximate Mapping 
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APPENDIX B. X.400 ENVIRONMENTS, COMPONENTS 
AND INTERFACE PROTOCOLS 








USER 
MHS 
MIS 
USER £77 ~~~ USER 
e———-y 9 P3/P7 Protocol Connectivity 


<.---.- -> P1 Protocol Connectivity 


LEGEND 


MTA: Message Transfer Agent 
UA: User Agent 

MHS: Message Handling System 
MTS: Message Transfer System 
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APPENDIX C. DATA THROUGHPUT COMPARISONS OF 
VARIOUS SYSTEMS. AFTER REF [20]. 


Representative System And Throughput 
2.4Kbps | 512 Kbps EES 










512 Kbps : ) ; ; paaes 3 j 7 





75 bps 













MILSTAR | NIPRNET 
& UFO SIPRNET 
(duplex) 


ATO @ 32.6hours | 1.02hours | 17.2sec | 
1.1 Mbytes . 
_ 


-All transmission times calculated using: | 
[8 data bits per byte * msg size] / system throughput 


Current 
FLTBCST 









-Message sizes are strictly information content and do not account for 
encryption, error correction, enveloping or transmission protocol overhead bits, 
which can vary depending on transmission system used. 


* Based on three times the current AUTODIN average message size (see 
Chapter I), no multimedia attachments. 
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